home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000025_news@newsmaster….columbia.edu _Thu Sep 10 13:25:42 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  3KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id NAA11279
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 10 Sep 1998 13:25:41 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id NAA26453
  7.     for kermit.misc@watsun; Thu, 10 Sep 1998 13:25:40 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: C-Kermit to MVS upload problems after upgrade to version 6
  12. Date: 10 Sep 1998 17:25:38 GMT
  13. Organization: Columbia University
  14. Lines: 63
  15. Message-ID: <6t922i$5o$1@apakabar.cc.columbia.edu>
  16. References: <35F80436.669@yahoo.com>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9189
  19.  
  20. In article <35F80436.669@yahoo.com>, Art L. <art1958@yahoo.com> wrote:
  21. : We have been having problems transfering files between C-Kermit on SCO
  22. : UNIX and Kermit on a IBM 390 mainframe running MVS.  We had no problems
  23. : until we upgraded our C-Kermit version from 5.190 to 6.192.  The problem
  24. : is that there several retry errors during the transmission.  I don't
  25. : have much information on the mainframe version other than it is old.  We
  26. : are connected thru a dialup connection via a local GTE Data Services
  27. : phone number.  The only kermit settings I was told to use are:
  28. :
  29. :     control quote=35
  30. :
  31. This is the default anyway.
  32.  
  33. :     max pack 1024
  34. :
  35. The command for this is SET RECEIVE PACKET-LENGTH 1024.
  36.  
  37. As noted in the manual, if a particular packet length results in trouble,
  38. then try a shorter one.
  39.  
  40. :     no pad characters
  41. :     eol=13
  42. :     CRC=1 byte checksum
  43. :     Block start =1
  44. : 
  45. These are the defaults anyway.
  46.  
  47. :  Packet Length:       1024     1024        Window Size: 3 set, 0 used 
  48. :
  49. Nothing suspicious here, except that you have also given the command:
  50.  
  51.   SET WINDOW 3
  52.  
  53. which you did not mention above.  But Kermit-370 does not do sliding
  54. windows.  This should cause no harm, since C-Kermit will negotiate down.
  55. But neither does it serve any useful purpose.
  56.  
  57. :  Packet timeouts: dynamic 1:0 
  58. :
  59. This is a difference between C-Kermit 5A and 6.0, that might account for
  60. some retries.
  61.  
  62. : The following is an example of my display after a file upload (I am
  63. : connecting at 14.4K):
  64. : 
  65. :   Transfer Rate, CPS: 1392 
  66. :          Error Count: 22 
  67. :           Last Error: (resend)
  68. :
  69. Well, first off, this is not so bad.  1392 cps on a 1440 cps connection
  70. is pretty good throughput for a half-duplex connection.
  71.  
  72. However, you should be able to eliminate the retries if C-Kermit 5A did
  73. not get them on exactly the same connection.  The most likely culprit is
  74. the new dynamic timeout feature, in which C-Kermit tries to figure out the
  75. packet round-trip time a per-packet basis, rather than using a fixed
  76. timeout.  Try giving C-Kermit a command like:
  77.  
  78.   SET SEND TIMEOUT 8 FIXED
  79.  
  80. This disables the dynamic timeouts and selects a fixed 8-second timeout.
  81.  
  82. - Frank